Some devices capable of concurrently running web applications e.g. to display web pages (web sites) may have limited resources wherein to properly run each application without affecting the performance of other applications. Web sites are typically viewed with a browser that manages operating system (OS) process creation based on user browsing actions: typing an address of the web pages such as a uniform resource locator (URL) or a uniform resource indicator (URI), clicking a link, pressing back/forward buttons. Concurrently open sites may be presented as tabs in a browser window. The browser may decide to run each tab in its own operating system process or to run all tabs in a single operating system process.
Creating a new process for each site may increase robustness because the OS takes care of isolating the processes. If a process crashes, it does not affect other processes. A downside may be that each new process consumes resources, especially memory. This is especially problematic for web applications, because dynamic memory allocations done by the browser engine are repeated for each process as is illustrated in Figure Y. The overhead when compared to similar application not created using web-technologies per process can be in the range of, for example, 3-7 MB, which may be a problem on desktop computers and critical on mobile devices. An alternative is to run several applications in a single process, which leads to less overhead per application. However, an application crash may result in process termination, which causes that all the other applications in the same process are also terminated.
Operating systems allow sharing of read-only code e.g. by using shared libraries. However, this mechanism only allows sharing library's read-only memory that remains static for all the processes that share it. Another mechanism that allows sharing dynamic memory is copy-on-write that can be used to share memory when forking a process. When copy-on-write is used, memory segments for a created child process are not allocated from physical memory but the child can use the pages of the parent process until either of them writes to the memory. Thus copying happens only when necessary, which saves memory.
In some embodiments running many browser processes concurrently consumes much memory which may cause some problems to the capability of the device to handle each processes efficiently enough. Each browser process may allocate even several mega bytes of memory, e.g. 3-7 MB, from a heap memory, depending on the complexity of the web site that the browser is showing. However, each browser instance may have significant areas of memory that are identical in each browser process, yet they are not shared. One problem may be to identify and allow sharing these dynamically allocated memory areas between browser process instances. When sharing is in place, another problem may be to allow effectively managing cached resources in the shared memory area.
The copy-on-write mechanism described above allows sharing memory for processes that have a parent-child relationship. Copy-on-write does not work for arbitrary processes even though those processes might be executing identical code. Copy-on-write and shared libraries are operating system level mechanisms that are not tied in any specific executable.
Web browsers may store web documents (e.g., hyper text mark-up language (HTML) pages, images) to reduce bandwidth usage, server load, and perceived lag, when the same resource is requested again. This client side cache can reside in memory or on disk. A server can set certain hypertext transfer protocol (HTTP) cache control headers that aid the client-side web browser in managing the cache. A web browser may have several types of caches and memory areas, such as HTTP cache and HTML5 application cache.